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(54) System and method for interfacing with multiple production scanners 



(57) A system and method for interfacing with pro- 
duction scanners is disclosed. A driver is provided which 
enables real-time communications between a scanning 
application and scanner devices. The driver includes an 
application program Interlace which Is coupled with one 
or more personality modules, one for each scanner de- 
vice. The personality module facilitates the command 



and control of a particular scanner device. The applica- 
tion program interface can communicate with more than 
one personality module at any given time to enable par- 
allel simultaneous operation of multiple scanner devic- 
es. The driver delivers resultant image data from the 
scans to a commonly accessible buffer where the scan- 
ning application can asynchronously retrieve it. 
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Description 

[0001] While just about every computer user owns 
their own printer and is capable of producing high quality 
documents, the ability to produce such documents In 
high volume and with special finishing features, such as 
binding, is still within the purview of the commercial print 
shops and corporate copy departments. High volume, 
finished production of documents is typically referred to 
as production printing. A production printer is a printing 
device capable of rapid production of large volumes of 
documents. Typically these printers have high paper 
handling capacity, the ability to draw on multiple media 
types from multiple sources and the ability to automat!- 
caliy finish a document such as by adding a binding. De- 
spite the automation provided by the production printer 
and the proliferation of computer technology, especially 
in the area of desktop publishing, production printing is 
still a complicated and often manual process. 
[0002] In a typical print shop, customers bring in orig- 
inal documents which they want turned into a finished 
product such as a bound booklet, a tri-fold brochure or 
a tabbed three ring bound notebook. In addition, they 
typically need a large volume of the finished product, for 
example, one thousand brochures. The combination of 
the original documents plus the instructions for produc- 
ing the finished product is called a "job". The documents 
can be brought in either in hard copy or electronic fonm, 
such as on floppy disk, compact disc or tape or can be 
transmitted to the print shop over a networic such as the 
Internet. 

[0003] Documents which are delivered in a hard copy 
fonm to the print ship must first be scanned into the 
shop's computer system so that they can be edited and 
otherwise prepared for production. Typically, the shop 
will have a one or more scanning stations consisting of 
one or more workstation computers coupled with one or 
more production scanners. As compared to consumer 
grade scanner devices, production scanners are high 
volume devices which are capable of scanning a high 
volume of originals continuously at high speed and at 
high resolution. While scanners tend to be very accurate 
and reliable devices, scanning documents can still be 
very resource intensive especially coupled with the high 
volume and high speed environment of a production 
print shop. 

[0004] In a typical operation, the operator will load a 
document into the scanner's automated feeder. Next, 
the operator will load the scanning application into the 
workstation, if not already loaded, and then instruct the 
scanner to scan the document. Once the scan is com- 
plete, the operator can view the scanned document and 
verify that a faithful reproduction was made, Often, how- 
ever, errors occur during the scanning process which 
may require rescanning. Such errors include operator 
errors or scanner malfunctions such as dust on the 
scanning glass, paper mis-feeds or lamp failures. Fur- 
ther, sometimesthe parameters of the scan, such as the 



image processing algorithms, contrast or color balance, 
need to be adjusted to account for the characteristics of 
the original document. These adjustments may not be 
apparent from a visual examination of the original doc- 
5 ument and may require several re-scans to get the pa- 
rameters set correctly. For large documents, such res- 
canning can be time consuming and costly 
[0005] The combination of large documents: the print 
shop's large workload and the inevitable errors that oc- 
10 cur requires that the scanning process be as efficient as 
possible. This typically translates into reducing operator 
errors and reducing the cost of error recovery and cor- 
rection. One solution is to provide intelligent and efficient 
scanning applications for the operator to use on the 
scanning workstation whbh anticipate problems and of- 
fer intuitive and efficient control of the scanning opera- 
tions. Unfortunately, such applications are often limited 
by the hardware and software interfaces to the scanners 
which fail to provide the necessary control over scanner 
operation and scanner feedback of status and event da- 
ta for en'or detection and correction. Further, these in- 
terfaces lack the ability to allow efficient management 
and operation of multiple scanners or scanners which 
are located remotely from the scanning woricstation, 
such as in a clean room environment. 
[0006] Accordingly, there is a need for an efTicient sys- 
tem and method for interfacing scanning applications 
with high volume production scanners. 



[0007] The present invention is defined by the follow- 
ing claims, and nothing in this section should be taken 
as a limitation on those claims. By way of introduction, 
the preferred embodiments described below relate to a 
driver for interfacing a first application program to first 
and second scanners. The first application program is 
operative to transmit first and second commands to the 
first and second scanners and the first and second scan- 
ners are operative to scan first and second documents 
and transmit first and second image data and first and 
second status data from the scans to the first application 
program. The driver comprises an application program 
interface ("API") coupled with the first application pro- 
gram and operative to receive the first commands from 
the first application program. The driver furthercompris- 
es a first scanner personality module ("SPM") coupled 
with the API and the first scanner and operative to re- 
ceive the first image data and the first status data from 
the first scanner and transmit the first commands to the 
first scanner and provide the first image data and the 
first status data to the first application program and a 
second scanner personality module ("SPM") coupled 
with the API and the second scanner and operative to 
receive the second image data and the second status 
data from the second scanner and transmit the second 
commands to the second scanner and provide the sec- 
ond image data and the second status data to the first 
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application program and wherein the second SPM Is fur- 
ther capable of operating substantially sinnultaneously 
with the first SPM. In addition, the API and the first and 
second SPM's facilitate real time communication be- 
tween the first application program and the first and sec- 
ond scanners. 

[0008] The preferred embodiments further relate to a 
method of interfacing a first application program to first 
and second scanners, the first application program ex- 
ecuting on a first computer coupled with the first and 
second scanners. The method comprises: initiating a 
first scan of a first document on the first scanner as di- 
rected by the first application program; initiating a sec- 
ond scan of a second document on the second scanner 
as directed by the first appiication program, as the first 
scan progresses; receiving first image data generated 
by the first scan as the first and second scans progress; 
receiving first status data from the first scanner as the 
first and second scans progress; receiving second im- 
age data generated by the second scan as the first and 
second scans progress; receiving second status data 
from the second scanner as the first and second scans 
progress; providing the first image data and the first sta- 
tus data to the first application program as the first and 
second scans progress; providing the second image da- 
ta and the second status data to the first application pro- 
gram as the first and second scans progress; adjusting 
the first scan as the first and second scans progress; 
and adjusting the second scan as the first and second 
scans progress.. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0009] 

FIG. 1 depicts a flow diagram illustrating a preferred 
production printing workflow. 

FIG. 2 depicts a flow diagram showing the user func- 
tionality woricfiow of the preferred embodi- 
ment 

FIG. 3 depicts a blocic diagram of a scanner interface 
according to a first embodiment. 

FIG. 4 depicts a blocic diagram of a scanner Interface 
according to a second embodiment. 

DETAILED DESCRIPTION OF THE PRESENTLY 
PREFERRED EMBODIIVIENTS 

[0010] Referring now to Figure 1, there is shown a 
flow diagram illustrating the production worl< flow 100 in 
a typical production print shop such as a commercial 
high volume copy or print shop. A woricflow is defined 
as the tasks, procedural steps, organizations or people 
Involved, required input and output infomfiation, and 
tools needed for each step in a business process. As 



will be discussed below, a workflow approach to analyz- 
ing and managing a business or process such as pro- 
duction printing can be combined with an object oriented 
approach, which tends to focus on the discrete objects 
5 and processes involved such as documents, pages, da- 
ta and databases. For the purposes of this disclosure, 
the term "object oriented", when applied to the disclosed 
embodiments, does not imply that an object oriented 
programming approach is the only method of implemen- 
ts tation of the disclosed embodiments. 

[0011] Figure 1 further depicts atypical computer net- 
work 112 for use in a print shop. In atypical digital print 
shop, there will be a network 11 2 of computer wori< sta- 
tions 114, 116, servers 118, 120, high volume input do- 
ts vice 124, and high volume output devfces 122 which 
make up the computer network 112. The servers 118, 
120 Include network servers 118 and print servers 120. 
The topology of the network 112 is typically structured 
so as to align with the workflow 100 of the print shop. 
20 The network 112 may be implemented as a wired or 
wireless Ethemet networi< or other fomri or local area 
network. Further the network 112 may include wired or 
wireless connections to wide area networks such as the 
Internet and connections to other local area networks 
25 such as through a virtual private network. 

[0012] The production workflow 1 00 includes the pro- 
cedural stages of job origination 102, job submission 
1 04, job preparation 1 06, print production 1 08 and final 
fulfillment 110. Alternatively, one or more of these pro- 
30 cedural stages may be combined as well as there may 
be other additional procedural stages. Job origination 
102 Is the procedural stage of receiving the documents 
and instmctions, which together are defined as a "job", 
from the customer Job origination 1 02 can occur when 
35 a customer physically brings his job, whether In hard 
copy or electronic fonn, to the print shop or otherwise 
transmits the job to the print shop, whether by phone, 
fax, postal malt, electronic mail or over a local area or 
wide area network such as over the Intemet. Note that 
40 a job may contain more than one document and more 
than one set of Instructions. For example, a job may con- 
tain many documents, each being one chapter of a 
book, along with a document containing a cover for the 
book. This exemplary job may include the instructions 
45 for producing the body of the book from the individual 
chapter documents and another set of instructions for 
producing the cover. In addition, as will be discussed 
below, there may be a third set of instructions for assem- 
bling the cover to the body of the book. 
50 [001 3] Job submission 1 04 Is the receipt of the job by 
the print shop and the entering of the job into the print 
shops production system or woricflow. Typically the in- 
structtons from the customer will be written down on a 
special fomn, known as a "ticket" or "job tickef. A ticket 
55 niay also be electronically created and maintained. Fur- 
themiore, pre-defined tickets may be available for 
standardized instructions. For example, the shop may 
have a pad of pre-printed tickets with the instructions to 
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duplicate the documents, three hole punch the final out- 
put and assemble the punched final output in a three 
ring binder. If this is a common request by customers, 
such pre-printed tickets can save time and resources. 
All the order taking clerk need do Is fill in any customer 
specific details such as the number of copies to produce. 
Pre-defined tickets may help to standardize operations 
and prevent errors in the transcription of Instructions 
from the customer In very simple print shops, job sub- 
mission 1 04 may simply be the receiving of the original 
documents and Instructions along with the creation of a 
ticket, placing the job in a paper folder and setting it in 
a physical queue for later handling in subsequent pro- 
cedural stages. 

[001 4] In print shops which handle jobs electronically, 
job submission 1 04 requires entering the job into the 
shops electronic production system. For documents 
which are brought in by the customer as hard copy, the 
documents must first be scanned electronically into the 
shop's computer system. For documents delivered in 
electronic fomn, the document data files must be loaded 
on the shop's computer system. 
[001 5] For the job submission stage 1 04, the compu- 
ter network 112 will include one or more "store fronf 
wori<stations 114. The store front workstations 114 are 
computer systems placed at the order taking desk, at a 
manned clerk's station or set out for customer self sen/- 
Ice use. These wori<stations 114 are used for the job 
submission stage 1 04 and typically will be configured to 
handle many different electronic media types such as 
floppy disk, compact disc, tape, etc. These stations 114 
may also be configured to receive jobs over the Internet 
or other fomi of network connection with customers. 
Further, these workstations 1 14 are typically configured 
to read many different electronic file fonnats such as 
those used by the Microsoft Office™ family of products 
manufactured by Microsoft Corporation, located in Red- 
mond, Washington or various other desktop publishing 
program file fomriats such as Aldus Pagemaker^** or 
QuariOCpress™. In addition, these stations 114 can also 
read "ready for printer" file formats, which will be dis- 
cussed later such as Portable Document Format™ 
("PDF"), Postscript™ ("PS") or printer control language 
("PCL"). Job preparation woricstations 116 can also ac- 
cept image formats such as Tagged Image File Fomnat 
("TIFF"), bitmap ("BMP") and PCX. These stations 114 
may also include a scanner 124 for scanning hard cop- 
ies of documents into the computer system. Scanners 
typically are compltoated devices to operate and some 
print shops may prefer to locate the scanners 1 24 in the 
job preparation stage 1 06 coupled with the job prepara- 
tion workstations 116 (as shown in the figure) for use 
solely by trained personnel as will be discussed below. 
In addition, the store front computers 114 also provide 
the ability to generate a ticket, electronically or In hard 
copy fonn, for the job containing all of the instructions 
for completing the production printing task. Th is process 
of generating the ticket may be automated, involving 



pre-defined tickets, manual or a combination thereof. 
[0016] Job preparation 106 involves preparing the 
documents for printing according to the instructions in 
the ticket. For documents that are submitted in hard 

5 copy fomi, job preparation 106 may include scanning 
the documents and creating a faithful and error free 
electronic reproduction. The documents, once in elec* 
tronicform, must also be distilled down or converted into 
a common file fomiat that the print shop can use to both 

10 edit and print the documents. This alleviates the need 
for operators to deal with multiple different progranns 
and eliminates the need to assemble complex docu- 
ments together for printing using different electronic file 
fonnats. 

15 [001 7] For example, a customer may bring in two dif- 
ferent documents, one being the body of a book and the 
other being the photographs to be inserted at specific 
pages. The customer may then instruct that the photo- 
graphs be inserted at particular pages and that the final 

20 assembly have continuous page numbers added. The 
body of the book may be In Microsoft Word™ format 
while the images of the photographs are in Adobe Pho- 
toshop™ fomnat. While the operator could figure out at 
which pages the images will be inserted and appropri- 

25 ately number the pages of the book and photographs 
using each individual software package, this is a very 
complex and time consuming process. It also requires 
that the operator be trained and familiar with a range of 
software packages and mns the risk that he will not be 

30 familiar with the particular package that the customer 
used. Therefore, it Is more efficient to distill each of the 
various file fonnats into a unified fomriat which allows 
the operator to prepare the job using a single software 
interface. In the preferred embodiments, all documents, 

35 whether provided in hard copy or electronically, are dis- 
tilled or converted into a "ready for printer" or "print 
ready" file format. In the preferred embodiments, the 
Portable Document Format™ is used as the ready for 
printer fomriat, developed by Adobe Systems, Inc., to- 

40 cated in San Jose, California. 

[0018] A ready for printer file format is defined as a 
file fomnat which contains both the data to be printed 
along with printer control instructions that can be directly 
interpreted by the internal processing engine of a printer 

45 or other fonn of hard copy output device in order to ras- 
terize the data image onto the output media. Rasteriza- 
tion is the placement of image data at a specific location 
on the output media. Such file formats include Portable 
Document Fomriat™ ("PDF") and Postscript™ ("PS") 

50 both manufactured by Adobe Systems, Inc., located in 
San Jose, California, as well as printer control language 
("PCL"), manufactured by Hewlett Packard, located in 
Palo Alto, California. Examples of non-ready for printer 
fonnats include the native application file fonnats for 

55 personal computer application programs such as Micro- 
soft Word"^". These file fonnats must be first converted 
to a ready for printer file fomnat before they can be print- 
ed. Furthennore, some image file fonnats, such as the 
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Tagged Image File Format ('TIFF") contain bit image da- 
ta only which Is already in a fomnat which specifies Its 
output location on the output media and does not con- 
tain printer control instructions for interpretation by the 
internal processing engine of the printer and therefore, 
for the purposes of this disclosure, is not a ready for 
printer file fonnat. By using a ready for printer forniat, 
rasterization of the image data can be delayed as close 
as possible to the final placement of the image data on 
the output media. This allows the most efficient use of 
the production print device 122 by allowing its internal 
control logic to optimize the rasterization process result- 
ing in output that is more likely to match with the oper- 
ator's expectations. 

[001 9] For the job preparation stage 1 06, the compu- 
ter network 106 includes job preparation workstations 
116, scanners 124 and network servers 118 coupled 
with the store front workstations 114 over the network 
112. Herein, the phrase "coupled with" is defined to 
mean directly connected to or Indirectly connected with 
through one or more intemnedlate components. Such in- 
temiediate components may include both hardware and 
software based components. The job preparation work- 
stations 116 preferably execute workflow management 
software which allows the operator to manage, edit and 
print jobs. The network server(s) 118 includes a docu- 
ment library which allows manipulation, management, 
storage and archiving of jobs, or just there respective 
documents and/ortlckets,as well as facilitates and man- 
ages the flow of jobs from the store front computers 1 1 4 
to the job preparation workstations 1 1 6 and from the job 
preparation workstations 1 1 6 to the print servers 1 20 or 
the production output devices 122. Exemplary docu- 
ment libraries Include Intra.Doc"^*^ document manage- 
ment system manufactured by Intranet Solutions, Inc., 
located in Eden Prairie, Minnesota and the DOCFusion 
document management system manufactured by Hum- 
mingbird, Inc., located in York, Ontario, Canada. In the 
prefen-ed embodiment, the job preparation workstations 
116 are Imagesmart^** Workstations, manufactured by 
Heidelberg Digital, L.L.C., located in Rochester, New 
York. Alternatively, an appropriate computer hardware 
platform such as that comprising a Pentium™ class 
processor or better, manufactured by Intel Corporation, 
located in Santa Clara, California, 64 megabytes of 
RAM or more, a 20 gigabyte hard disk or larger and ap- 
propriate display device may be used. Further, In the 
prefened embodiment, the network servers 118 prefer- 
ably comply with the Open Document Management Ar- 
chitecture ("ODMA") standard and provide document 
management capabilities and scaleable storage. 
[0020] The job preparation workstations 1 1 6 also pro- 
vide the capability of the print shop to add value to the 
print production process by offering services to the cus- 
tomer. Such services Include the ability to modify docu- 
ments provided by the customer to add features that the 
customer could not or would not add himself. Such fea- 
tures include adding page numbers across multiple doc- 



uments, bates numbering, adjusting page layout fortab 
stock and aligning the output to account for binding. Fur- 
ther the job preparation workstations 1 1 6 provide the ca- 
pability to fix errors in the documents such as removing 

5 artifacts in scanned Images and masking over unwanted 
text or markings. The job preparation workstations 116 
can also be used to prevent inaccuracies in the finished 
output caused by the printing or binding process. Such 
inaccuracies include binder's creep which happens after 

10 a document is imposed into a booklet/pamphlet using a 
signature Imposition. Binder's creep occurs when the 
placement of the images on the paper fails to account 
for the thickness of the binding as a function of the 
number of pages In the book causing the Image on the 

15 pages to shift inward as you get closerto the cover. Bind- 
er's creep is prevented by shifting Image slightly when 
performing the signature imposition on the document. 
In addition, the job preparation workstation 116 allows 
the operatorto manage and layout the document pages 

20 for final output, also known as "imposition" and "signa- 
ture imposition". In addition, the operator can shuffle 
pages, reverse pages, insert blank pages, trim and shift 
pages, create bleeds and place multiple pages on a 
sheet, also known as "n-up" to create proof sets, bro- 

25 chures or pamphlets, etc. Further the job preparation 
workstation 1 1 6 pemnits the operator to add annotations 
to the document such as bates numbers, page numbers, 
logos and watemriarks. All of these service add value to 
the final output. Formatting and other modifications to 

30 the document can be globally applied to the entire doc- 
ument, such as a shifted margin or may be applied only 
to select pages. Such alterations to the document are 
known as document/page features or attributes. Fur- 
ther, these alterations are also known as document or 

35 page exceptions since they typically override specific in- 
stances of the original document fonnattlng as set by 
the customer. 

[0021 ] The next stage in the print production workflow 

100 is the print production stage 108. In the print pro- 

40 ductlon stage 108, the final form of the documents for 
printing Is sent to a print server 120 which will distribute 
the job to the final output device 122. In manual print 
shops, this stage 108 would be similar to an operator 
manually taking the ready for production job over to the 

45 desired output device 122 to start the job. The print pro- 
duction stage 108 manages the output resources of the 
print shop. Such management includes queuing jobs to 
the proper devices 1 22 In the shop, routing jobs to avail- 
able devices 122, balancing the load placed on the var- 

50 ious devices 122, and pre-processing jobs, such as 
splitting or RIP'ing the job, prior to sending it to a partic- 
ular device 122. RIP stands for Raster Image Processor 
and is the hardware and/or software whfch converts 
ready for printer data Into raster Images. It Is also a com- 

55 nnon term for rasterizing a page image on to the output 
media. 

[0022] The print server 120 used in the print produc- 
tion stage 1 08 is coupled with the job preparation work- 
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stations 116 and the network server 118 over the net- 
work 112. Further, the print server 120 is coupled with 
the various output devices 122 In the print shop. Note 
that some output devices 1 22 may not support electron- 
ic transfer of the data to be output and may require a 
manual step for operation. Such devices may include a 
special binding machine which requires that the partially 
finished documents be manually transferred to the bind- 
ing machine to complete the production. The print server 
120 is preferably implemented as a separate computer 
coupled with the network 1 1 2, however, software based 
print servers running on a network server 118, job prep- 
aration workstation 116 or store front workstation 114 
may also be used. In the preferred embodiment, the 
printer server 120 includes an independent computer 
woricstation, typically running a UNIX or Windows NT 
operating system, a software print server engine and a 
software print server application. The print server appli- 
cation offers the user interface ability to configure and 
manage the print server operation. The print server en- 
gine perfomns the automated processes of the print 
server. These processes include spooling and queuing 
jobs and job content (i.e. the document), directing the 
jobs to specific production output devices based on the 
attributes of the print job and how these attributes are 
satisfied by the print engine, load balancing jobs among 
the various production output devices to keep all printers 
fully utilized, e.g. to split color from black and white jobs, 
and acting as a communication gateway where it can 
accept multiple input communication and print protocols 
translating them to the communication and printprotocol 
the production output device 122 understands. 
[0023] The final stage of the production printing work- 
flow 100 is the final fulfillment stage 110. The final ful- 
fillment stage 1 1 0 is the stage where the finished output 
Is produced on the production output device 1 22. A pro- 
duction output device is a computer output device, such 
as a printer, designed for high volume production of 
printed documents. Such devices preferably include the 
ability to produce large quantities of documents with 
mixed media types and various degrees of finishing, 
such as stapling or binding, at very high speed. Exem- 
plary output devices include the Digimaster'''M Digital 
High Volume Printer manufactured by Heidelberg Digit- 
al, L.L.C., located in Rochester. New York, and the Nex- 
Press*^** Color printer manufactured by NexPress, Cor- 
poration, located in Rochester, New York. 
[0024] Referring now to Figure 2, there is shown a 
flow diagram showing the user functionality woricflow 
200 of the preferred embodiment job submission and 
preparation stages 1 04, 1 06. The user workflow 200 In- 
cludes an input source stage 202, a preflight stage 204 
and a production stage 206. In the input source stage 
202, all of the documents of the job are collected togeth- 
er from the different input sources 208. As detailed 
above, all of the collected documents are converted to 
a ready for printer fonmat, preferably a Portable Docu- 
ment Forniat^**. This conversion can be a manual or au- 



tomated process or a combination thereof. For example, 
a special directory can be created on the networic server 
118 where data files in various file formats can be 
placed, for example, by the cleri< who accepts the doc- 
5 uments from the customer and inputs them into the store 
front workstation 114. Automated logic which watches 
this directory, will see the placement of files and auto- 
matically convert them (or flag them for manual conver- 
sion) into a ready for printer fonmat. Any documents 
10 which the automated logic cannot handle can be flagged 
for manual conversion. The converted documents are 
then passed to prefilght stage 204 where they are pre- 
pared for production. This transfer of converted docu- 
ments can occur by moving the documents to a special 
15 directory on the network server 1 1 8 where they can be 
accessed by the job preparation workstations 1 1 6 or by 
transmitting the documents to the job preparation work- 
station 116. This process can be manual or automated 
and may involve placing the documents in a queue of 
documents waiting to be prepared for production. Fur- 
ther, this process may Include a manual or automated 
detemiination of the capabilities, skill level or training 
level of the various operators currently logged into the 
available job preparation workstations 1 1 6 as well as the 
cun-ent load/backlog of job In their respective queues. 
Taking these factors into account, job can be automati- 
cally or manually routed to the operator best able to han- 
dle the job both technically and in an expedient manner. 
This functionality can be Implemented by creating an op- 
erator database which tracks the capabilities, skill level 
and training level of the various operators who work In 
the print shop. This database can be coupled with queue 
management software which balances the loads/back- 
logs of job at each station 116. 
[0025] In the preflight stage 204, the documents can 
be assembled, such as in a book, annotated, edited, and 
have imposition or other page features applied. Once 
the documents are prepared for production, they are 
passed to the production stage 206. In the production 
stage 206, the prepared documents along with the pro- 
duction instructions (from the tickets) are submitted to 
the print server or directly to the production output de- 
vice 122 using a file downloader such as the Print File 
Downloader^ application program manufactured by 
Heidelberg Digital, L.L.C.. located in Rochester, New 
York. This user functionality workflow 116 may be imple- 
mented as a combination of hardware, software and 
manually executed components and may involve one or 
more of the components detailed in the production print- 
ing workflow above. 

[0026] When a job is brought into the print shop in 
hard copy fonm, it must first be scanned into the shop's 
computer system as described above. The scanning 
takes place in the job submission 1 04 or the job prepa- 
ration 106 stages of the shop's woricflow. Typically, the 
document is loaded into an automated paper feeder of 
a production/high volume scanner 124 which is coupled 
with the job preparation wori<stations 116 (the "scanner 
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host" or "scanner host workstation"). In the preferred 
embodiment, the production scanner 124 is an Image- 
Direct Scanner, manufactured by Heidelberg Digital, L. 
L.C., located in Rochester, New York. The operator then 
Initiates and controls the scan from the Job preparation s 
workstation 116 coupled with the scanner 124. The op- 
erator interacts with the scanner 124 using a scanning 
application program loaded on the job preparation work- 
station 116. The scanning application provides the abil- 
ity to set the scanner parameters, initiate and control 
scans and view the results of the scan. The scanning 
application is typically a computer program written by a 
third party company different from the manufacturer of 
the scanner 124 or the job preparation workstation 116, 
one example is Adobe Systems, Inc., located in San 
Jose, California. 

[0027] As is known in the art, application programs ex- 
ecuting on a computer workstation interface with exter- 
nal hardware devices coupled with that workstation us- 
ing interface programs called drivers. A driver acts like 
a translator between the device and programs that use 
the device. Each device coupled with a computer typi- 
cally has its own set of specialized commands that only 
its driver knows. In contrast, most application programs 
only know how to access these devices by using generic 
commands. The driver, therefore, accepts generic com- 
mands from an application program and then translates 
them into specialized commands for the device. Essen- 
tially, the path between the operating system and virtu- 
ally all hardware not located directly on the computer's 
motherboard goes through these special driver pro- 
grams. Much of a driver's function Is as translator be- 
tween the electrical signals of the hardware sub-sys- 
tems and the high-level programming languages of the 
operating system and application programs. For exam- 
ple, drivers take data that the operating system has de- 
fined as a file and translates them into streams of bits 
placed in specific locations on storage devices, or a se- 
ries of laser pulses in a printer. Because there are such 
wide differences in the types of hardware controlled 
through drivers, there are necessarily differences In the 
way that the driver programs function, however most 
drivers are executed when the device is required, and 
function much the same as any other process. The op- 
erating system will frequently assign high priority mem- 
ory blocks to drivers so that the hardware resource can 
be released and readied for further use as quickly as 
possible. One reason that drivers are separate from the 
operating system is so that new functions can be added 
to the driver-and thus to the hardware subsystems-with- 
out requiring the operating system itself to be modified, 
recompiled and redistributed. Through the development 
of new hardware device drivers, such development of- 
ten perf omned or paid for by the manufacturer of the sub- 
systems rather than the publisher of the operating sys- 
tem, input/output capabilities of the overall system can 
be greatly enhanced. 

[0028] An exemplary driver program is a printer driver 



which allows an application program to print output on 
a printer coupled with the workstation, whether directly 
or indirectly, such as over a networi<. Different printers 
manufactured by different companies typically offer dif- 
ferent features and utilize different commands which are 
proprietary to that company. As explained above, a driv- 
er program allows a layer of abstraction between an ap- 
plication program and the variety of available printers so 
that the application program does not need to maintain 
its own ability to utilize all of the different printers that 
are available or be upgraded to handle later developed 
devices. The driver provides a standard software inter- 
face forthe application program to interact with, typically 
referred to as an Application Program Interface or API. 
The driverthen translates those generic interactions into 
the device specific commands to control the attached 
device. In addition, drivers can also present a user in- 
terface for controlling vendor specific functions of the 
particular device. For example, a printer that supports 
duplexing can be interfaced with using a driver that can 
present a user interface allowing the operator to choose 
the duplexing function. Further, the driver is also pro- 
grammed to control the specific hardware Interface that 
connects the device to the woricstation. Such hardware 
interfaces include Small Computer System Interface 
("SCSI"), Universal Serial Bus ("USB"), serial, parallel, 
and IEEE 1394 ("FireWire") as are known in the art. If a 
different device is attached, a user need only load a new 
driver to allow the application program to interact with 
the new hardware. 

[0029] Scanners 1 24 are typically physically coupled 
with the job preparation woricstations 1 1 6 utilizing a SC- 
SI interface. 

[0030] Scanner drivers are typically of two types, 
TWAIN, as defined by the TWAIN group located in Boul- 
der Creek, California and the Image and Scanner Inter- 
face Specification ("ISIS") developed by Pixel Transla- 
tions, Inc., located in San Jose, Califomia and also spec- 
ified via American National Standards Institute specifi- 
cation ANSl/AIlM MS61-1996. While TWAIN and ISIS 
based drivers provide the basic functionality required for 
low volume scanning, they typically prove inadequate 
forthe needs of production/high volume scanning as is 
done in a production print shop. Such needs include the 
abilities to scan multiple high volume originals, continu- 
ously at high resolution and high speed coupled with ef- 
ficient error detection, correction and diagnostic capa- 
bilities. Further, print shops often need to simultaneous- 
ly operate multiple scanners 124 manufactured by dif- 
ferent manufacturers in an efficient manner and with a 
minimum of resources. This usually requires that multi- 
ple scanners 124 be connected to and operated from 
one job preparation workstation 11 6 by a sole operator 
[0031 ] Drivers written under the TWAIN specification 
are job oriented. A job is defined as a collection of all of 
the scanning attributes, e.g. the scanning and image 
processing attributes such as Image resolution and bit 
depth, all of the constant/scanner-independent at- 
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tributes such as paper plex (simplex or duplex) and at- 
tributes specific to the particular scanner such as bar 
code reading capability. TWAIN drivers set up all of the 
job paranneters and then initiate the scan . Once initiated, 
however, the parameters cannot be altered until the 
scan is completed or halted. Therefore, if a parameter 
Is set incorrectly, the scan needs to be stopped and com- 
pletely restarted. This can be problematic rf, for exam- 
ple, a scan en*or occurs on the 1 0th page of a 1 00 page 
document. In this example, the scan must be allowed to 
complete before the scanner 1 24 can be adjusted to ac- 
count for the error or the scan must be stopped, re-load- 
ed and re-started, incurring significant delay in either 
case. 

[0032] Further, TWAIN based drivers deliver the 
scanned document one Image at a time from the scan- 
ner hardware interface to the scanning application. This 
means that the driver must handshake each image (i.e. 
interrupt the application, establish a connection and de- 
liver the data) to the application program from the hard- 
ware interface of the scanner. This creates unnecessary 
overhead for the application program, especially in high 
volume environments and In cases where a single scan- 
ning application is being utilized to manage multiple 
scanners 1 24 which are simultaneously scanning. In ad- 
dition, while TWAIN drivers support the connection of 
multiple scanners to the same workstation, they do not 
support multiple scanners being operated simultane- 
ously from the same workstation. The operator must 
choose one particular scanner 124 to use for scanning 
at any given time and wait for that scan to complete be- 
fore choosing a different scanner 124. 
[0033] ISIS drivers are device/scanner specific driv- 
ers and do not provide a user interface to the scanner. 
Instead, ISIS drivers require that the application pro- 
gram provide the user interface to the scanner. Further, 
the ISIS standard fails to provide a comprehensive 
method of defining scanner jobs like the TWAIN stand- 
ard does through its extensive use of user specifiable 
attributes. ISIS interfaces do not provide the ability to 
display a scanner specific user interface, like TWAIN 
drivers do, in orderfor the user to setup the scanner job. 
The ISIS approach is to require the application to pro- 
vide all of the user Interface software. This approach is 
functional in the case of a scanning application that 
needs to be able to work with multiple types of scanners 
124 while providing a coherent user interface in the use 
of those scanners 124. ISIS is not as robust as TWAIN 
in providing a comprehensive method to define the 
scanner job. Often the scanner vendor needs to request 
enhancements to the application program interface 
("API") of ISIS in order to perfonn the functionality re- 
quired. Further, after the application perfomns the nec- 
essary interaction with the ISIS API to start the scanning 
process for a set of original documents loaded in the 
scanner's 124 automatic sheet feeder, the ISIS driver 
consumes ail of the computing power of the host com- 
puter until the entire document has been scanned in. 



Finally, ISIS based drivers do not support multiple scan- 
ners being operated simultaneously from the same 
workstation. Applications written for ISIS drivers as- 
sume that only one driver Is loaded on the host compu- 
5 ter. 

[0034] Both TWAIN and ISIS based drivers further 
lack the ability to supply real-time infonnation back to 
the scanning host workstation computer. Such real time 
infomnation or status data Includes status infonnation 
10 such as lamp temperature and scanner parameter set- 
tings. Status data further includes infomnation about 
scanning events such as a paper mis-feed or lamp-fail- 
ures. By real time, it is meant that status data can be 
provided back to the scanning application while the scan 
15 is progressing and without waiting until the scan com- 
pletes. Real time is a level of computer responsiveness 
that a user senses as sufficiently immediate or that en- 
ables the computer to keep up with some external proc- 
ess (for example, to present visualizations of the weath- 
er as it constantly changes). 

[0035] The present embodiments describe an im- 
proved scanner interface solution for application devel- 
opers referred to herein as a Virtual Scanner Driver or 
VSD. The prefen-ed embodiments comprise the ability 
to have a single application communicate with a single 
API independent of the brand of scanner 124 which Is 
coupled with the job preparation workstation 116. Fur- 
ther, a personality module or PIV! is provided which en- 
compasses the vendor specific functionality of the par- 
ticular scanner 124 coupled with the job preparation 
woricstation 124. The PM Interfaces the VSD API to the 
scanner 124. The PIVI accommodates three aspects of 
scanning: the communications method to the scanner 
124 (USB, SCSI, serial, parallel, FireWire, etc.), the de- 
livery method of the image data and status data coming 
from the scanner 124 and any enhanced image 
processing required over and above that provided by the 
scanner 124 itself. 

[0036] By providing a PM loaded on the job prepara- 
tion workstation 116 for each type of scanner 124 cou- 
pled with the woricstation 1 1 6, the VSD can automatical- 
ly utilize the appropriate PM when instructed to initiate 
a scan on a particular scanner 124 by the scanning ap- 
plication. The VSD dynamically chooses which PM to 
use based on the scanner 124 chosen by the operator. 
[0037] Further the VSD and PM facilitate, or enable, 
real time communications between the scanner 1 24 and 
the woricstation 116, i.e. the VSD and PM enable the 
scanner 124 to send image and/or status data to the 
workstation 116 and the woricstation 1 1 6 to send com- 
mands to the scanner 124 while a scan is in progress 
on the scanner 1 24. For example, the VSD provides re- 
al-time feedback of scanner 124 status data, including 
scanner status, events and other telemetry data provid- 
ed by the scanner 124. This information is provided 
while a scan is in progress and once the scan com- 
pletes. This Infonnation can be used by the operator to 
adjust the scan parameters while the scan is progress- 
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ing without the need to halt or restart the scan. This is 
useful when the scan quality is slowly degrading but not 
yet at a point where the scan job Is compromised. In 
such situations, a real-time adjustment, I.e., a command 
from the workstation 116, can Improve the scan quality 
and eliminate the degradation without the delay of halt- 
ing and/or restarting the scan. Further, applications such 
as diagnostic applications can utilize the real-time feed- 
back provided by the VSD to detect impending hardware 
failures such lamp failures. Automated scan quality ap- 
plications can monitor the quality of scans in progress 
and automatically adjust various scanner parameters 
and image processing algorithms to correct for degra- 
dation in quality such as dust on the scanner glass or 
skewed images caused by a mis-fed original. Such ap- 
plications can further automate the scanning process 
and reduce operator en'ors, thereby improving efficien- 
cy and throughput. 

[0038] In addition, the VSD delivers image data to the 
scanning application without handshaking each image 
to the application. In the preferred embodiments, image 
data, typically consisting of individual image files for 
each scanned page of a document, is delivered to a buff- 
er storage commonly accessible to the VSD and the 
scanning application, preferably located within the job 
preparation workstations 116 file system. This buffer 
storage can be located in random access memory, on a 
local hard disk or on a network disk. In the preferred 
embodiments, the VSD utilizes a Unifomn Resource Lo- 
cator as specified by the Hypertext Transfer Protocol, to 
provide a unifomn and universal file based delivery 
method which is Independent of the device hardware 
coupled with the Job preparation workstation 116. It will 
be appreciated that other file delivery protocols can also 
be used including File Transfer Protocol ("FTP" and 
"TFTP") and Network File System ("NFS) as are known 
in the art. By delivering the image data to a buffer stor- 
age, the scanning application can retrieve the image da- 
ta asynchronously when it needs the data. This allows 
the scanning application to efficiently operate and sup- 
port the simultaneous operation of multiple scanners 
from the same scanning application and job preparation 
workstation 116. Further, this allows the VSD to execute 
the delivery of image data at substantially the same 
speed as the rated speed of the scanner 1 24 even when 
multiple scanners 124 are operating. In the case of the 
preferred scanner, the ImageDirect scanner, this rate is 
65 pages per minute. 

[0039] Referring now to Figure 3 there is shown a 
block diagram of a production scanning system utilizing 
a first embodiment of a VSD 308. The system 300 in- 
cludes a job preparation workstation 116, a scanner 
302, a scanning application 306 and a buffer storage 
316. The job preparation workstation 116 is preferably 
a Scan Hosfrw station as used by the Digimaster^'* 
9110, manufactured by Heidelberg Digital, L.L.C., locat- 
ed in Rochester, New York. Alternatively, an appropriate 
computer hardware platfonn such as that comprising a 



Pentium™ class processor or better, manufactured by 
Intel Corporation, located in Santa Clara, California, 64 
megabytes of RAM or more, a 20 gigabyte hard disk or 
larger and appropriate display device may be used. Fur- 

5 therthe scanner 302 Is preferably an ImageDirect Scan- 
ner also manufactured by Heidelberg Digital L.L.C. The 
scanner 302 is coupled with the job preparation work- 
station 116 using a hardware interface 304. The hard- 
ware interface 304 is preferably a SCSI interface. Alter- 

10 natively, the hardware interface 304 can be a USB, 
FireWire, serial or parallel interface. Further, the scan- 
ner 302 can be coupled with the job preparation work- 
station 116 via a network utilizing an Ethernet or other 
comparable network interface/architecture as is known 

IS in the art. Preferably, the hardware interface 304 sup- 
ports high bandwidth, high throughput bidirectional 
communbations. The buffer storage 31 6 is preferably a 
hard disk drive coupled with the job preparation work- 
station's 1 1 6 file system, and preferably physically con- 

20 nected with the station 1 1 6. In alternative embodiments, 
the buffer storage 306 may be a random access mem- 
ory, a dedicated hard drive coupled with the scanner 302 
or a remote disk drive such as a networi< drive. It is pre- 
ferred that the operating system of the job preparation 

25 woricstation 1 1 6 allow common access to the buffer stor- 
age 316 from both the scanning application 306 and the 
VSD 308. 

[0040] The scanning application 306 is a software 
program executing on the job preparation woricstation 

30 116 which allows an operator to initiate and control scan 
jobs as well as view and manipulate the results of the 
scans, such as editing the resultant images, or by send- 
ing the results to a production printer 122. In the pre- 
ferred embodiments, the scanning application 306 is the 

35 Scan Host software as used by the Digimaster 9110, 
manufactured by Heidelberg Digital, L.L.C, located in 
Rochester, New York. The system 300 further includes 
the VSD 308 which Is coupled with the scanning appli- 
cation 306. The scanning application 306 communi- 

40 cates with the VSD 308 via the VSD's 308 API 31 0 as 
is known in the art. The API 310 provides a coherent 
unifomn user interface to the various scanners 302 that 
can be used by the scanning application 306. The VSD 
308 further includes one or more PM's 31 2A, B. A PM 

45 31 2A, B is defined for each of the scanners 302 which 
are connected or capable of being connected with the 
job preparation workstation 1 1 6. The PM 31 2A, B bridg- 
es the interface gap between the API 31 0 and the hard- 
ware interface 304 to the scanner 302. The PIVI 31 2A, 

50 B encompasses the scanner specific attributes of the 
particular scanner 302 and translates the generic com- 
mands from the API 310 into the specific commands 
which the scanner 302 understands. Further, the PM 
312A, B includes the hardware interface connectivity 

55 31 4A. B which formats and transmits those commands 
over the particular hardware interface 304 used to con- 
nect the scanner 302 to the job preparation woricstation 
116. The PM 31 2A, B accommodates the communica- 
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tions interface to the scanner device 302 so the scan- 
ning application 306 does not have to deal with this as- 
pect. This includes initializing and maintaining the com- 
munications. As described above, the communication's 
interface can a SCSI, FireWire, Fibre Channel, USB, s 
Serial or Parallel, etc. type interface. The PM 31 2A, B 
further provides a direct interface 31 8 to the buffer stor- 
age 316. This allows the PM 31 2A, B to deliver image 
data from the scanner 302 to the buffer storage 316 
where the scanning application 306 can asynchronously io 
retrieve it. The PM 31 2A, B is responsible for delivering 
the scanned Image data to the destination buffer storage 
31 6 which may be located locally on the job preparation 
station 116 or remotely, such as on a network drive. To 
enable image data delivery to a remote buffer storage is 
31 6, the PM 31 2A, B may employ some forni of file sys- 
tem protocol such as FTP or NFS or other protocol such 
as HTTP as described above. Finally, the PM 31 2A, B 
identifies and provides image processing features that 
may not be supported (are not native) on the scanner 20 
device 302 itself. Where a particular image processing 
feature is not available on the scanner 302, the PM 
31 2A, B provides a software substitute. In this way, the 
VSD 308 can present a unifonn feature set to the scan- 
ning application 306 and is not limited by the actual 25 
available feature set of the scanner 302. In this way, the 
VSD 308 is logically partitioned into the common API 
310 which interfaces to the scanning applications 306 
and the PM 31 2A, B which embodies scanner/vendor 
specific interface attributes. Further, as was discussed 30 
above, the API 310 is capable of receiving commands 
from the scanning application 306 and passing them on 
to the PM 31 2A, B, and the PM 31 2A, B is capable of 
passing those commands onto the scanner 302 while a 
scan is in progress and while image or status data is 35 
being transferred from the scanner 302 to the PM 31 2A, 
B which transmits it to the buffer storage 316 for later 
retrieval by the scanning application 306, thereby facil- 
itating/enabling real time communication between the 
scanner 302 and the scanning application 306/worl<sta- 40 
tion 116. 

[0041] Referring now to Figure 4 there is shown a 
block diagram of a second scanning system 400 utilizing 
a second embodiment of a VSD 408. This figure shows 
a scanning system 400 capable of simultaneously uti- 45 
lizing multiple scanners 402A-C. The scanning system 
400 includes a job preparation workstation 116 coupled 
with scanners 402A-C using hardware interfaces 
404A-C. It will be appreciated that each scanner 402A'C 
may be of a different type and may connect with the job so 
preparation woricstation 116 using a different hardware 
interface 404A-C as described above. Further, the scan- 
ning system 400 includes a commonly accessible buffer 
storage area 41 6, as described above, to allow the PM's 
41 4A-C to deliver image data at the scanner's 402A-C ss 
rated speed and allow the scanning application 406 to 
asynchronously retrieve the image data without the 
need for handshaking. 



[0042] Figure 4 further shows PM's 414A-C coupled 
with the VSD API 410, These PM's 414A-C operate as 
described above for the embodiment of Figure 3. Es- 
sentially, the scanning application 406 initiates scans on 
the scanners 402A-C by sending the appropriate com- 
mands to the VSD API 41 0. The API 41 0 then loads the 
appropriate PM's 412A-G for each scanner 402A-C. 
Each PM 412A-C can coexist and co-execute In a sub- 
stantially parallel fashion with the other PM's 41 2A-C al- 
lowing simultaneous operation of the scanners 402A-C 
from the single scanning application 406 and VSD API 
41 0. Further, the VSD API 41 0 and PM's 412A-C facili- 
tate/enable the scanning application 406/Wori<station 
1 1 6 to communicate with/operate and receive image da- 
ta from one or more of the scanners 402 A-C in real time 
as scans are progressing on those scanners 402A-C as 
described above. In alternative embodiments, such si- 
multaneous scanning capability can be implemented by 
allowing multiple scanning applications 406 to execute 
and operate in a substantially parallel fashion on the job 
preparation workstation 116. Such multitasking is well 
known in the art. Further, the scanning application 406 
can communicate with a single VSD API 408 with mul- 
tiple PM's 412A-C controlling multiple scanners 402A'-C 
as described or, alternatively, the VSD API 408 can, it- 
self, be instantiated multiple times on the job preparation 
workstation 116 with each PM 412A-C. 
[0043] It is therefore intended that the foregoing de- 
tailed description be regarded as illustrative rather than 
limiting, and that it be understood that it is the following 
claims, including all equivalents, that are intended to de- 
fine the spirit and scope of this invention. 



Claims 

1 . A driverfor interfacing a first application program to 
first and second scanners, said first application pro- 
gram operative to transmit first and second com- 
mands to said first and second scanners and said 
first and second scanners operative to scan first and 
second documents and transmit first and second 
image data and first and second status data from 
said scans to said first application program, said 
driver comprising: 

an application program interface ("API") cou- 
pled with said first application program and op- 
erative to receive said first commands from said 
first application program; 
a first scanner personality module ("SPM") cou- 
pled with said API and said first scanner and 
operative to receive said first image data and 
said first status data from said first scanner and 
transmit said first commands to said first scan- 
ner and provide said first image data and said 
first status data to said first application pro- 
gram; 
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a second scanner personality module ("SPM") 
coupled with said API and said second scanner 
and operative to receive said second image da- 
ta and said second status data from said sec- 
ond scanner and transmit said second com- s 
mands to saldsecond scanner and provide said 
second image data and said second status data 
to said first application program and wherein 
said second SPM is furtlier capable of operat- 
ing substantially simultaneously with said first io 
SPM; and 

wherein said API and said first and second 
SPM's facilitate real time communication be- 
tween said first application program and said 
first and second scanners. 

2. The driver of Claim 1 , wherein said first scanner is 
of a first type, said first SPM being associated with 
said first type and said second scanner is of a sec- 
ond type, said second SPM being associated with 20 
said second type. 

3. The driver of Claim 1 , wherein said first and second 
SPM's are further operative to simultaneously re- 
ceive said first and second image data and said first 25 
and second status data from said first and second 
scanners while transmitting said commands to said 
first and second scanners. 

4. The driver of Claim 1 , wherein said first and second 30 
SPM's are further operative to provide said first and 
second image data to a buffer asynchronously ac- 
cessible by said first application program. 

5. The driver of Claim 4, wherein said buffer comprises 35 
a hard disk. 

6. The driver of Claim 1 , wherein said first and second 
SPM's are further operative to substantially simul- 
taneously transmit said first and second commands 
to said first and second scanners while said scans 
are In progress. 

7. The driver of Claim 6, wherein said commands com- 
prise commands to adjust scan quality. ^5 

8. A system Implemented in a computer workstation 
for interfacing one or more application programs ex- 
ecuting on said workstation to at least two scanners 
coupled with said workstation, each of said at least so 
two scanners comprising a scanner Interface, said 
system comprising: 

A first module operative to receive commands 
from said one or more application programs ss 
and provide image data and status data to said 
one or more application programs; 
A second module coupled with said first module 



and associated with a first of said at least two 
scanners, said second module being coupled 
with said scanner interface of said first of said 
at least two scanners and operative to receive 
said commands from said first module and 
translate said commands to said scanner inter- 
face, said second module further operative to 
receive image data and status data from said 
first of said at least two scanners via said scan- 
ner Interface and transmit said Image data and 
said status data to said first module; and 

wherein said second module Is capable of 
translating said commands to said scanner inter- 
face and receiving said image data and said status 
data while a scan is in progress on said first of said 
at least two scanners; and 

wherein said first module Is capable of receiv- 
ing said commands from said one or more applica- 
tion programs and providing said Image data and 
said status data to said one or more application pro- 
grams while a scan Is in progress on said first of 
said at least two scanners. 

9. The system of Claim 8, wherein said first module is 
further operative to provide a unifonm interface to 
all of said one or more applications. 

10. The system of Claim 8, wherein said scanner inter- 
face further comprises a hardware interface and a 
software interface. 

11. The system of Claim 8, wherein said commands 
comprise commands to readjust a scan In progress. 

12. The system of Claim 11, wherein said commands 
comprise commands to readjust scan quality of said 
scan in progress. 

13. The system of Claim 8, further comprising: 

a third module coupled with said first module 
and associated with a second of said at least 
two scanners, said third module being coupled 
with said scanner interface of said second of 
said at least two scanners and operative to re- 
ceive commands from said first module and 
translate said commands to said scanner inter- 
face, said third module further operative to re- 
ceive image data and status data from said sec- 
ond of said at least two scanners via said scan- 
ner interface and transmit said image data and 
said status data to said first module; and 
wherein said second module is capable of 
translating said commands to said scanner in- 
terface and receiving said image data and said 
status data while scans are in progress on said 
first and second of said at least two scanners. 
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14. The system of Claim 8, further comprising a buffer, 
said buffer capable of being asynchronously ac- 
cessed by said one or more application programs 
and wherein said first module is further operative to 
store said image data in said buffer. 

15. The system of Claim 14, wherein said buffer com- 
prises a hard disk. 

16. A method of Interfacing a first appiication program 
to first and second scanners, said first application 
program executing on a first computer coupled with 
said first and second scanners, said method com- 
prising: 

(a) initiating a first scan of a first document on 
said first scanner as directed by said first appli- 
cation program; 

(b) initiating a second scan of a second docu- 
ment on said second scanner as directed by 
said first application program, as said first scan 

progresses; 

(c) receiving first image data generated by said 
first scan as said first and second scans 
progress; 

(d) receiving first status data from said first 
scanner as said first and second scans 

progress; 

(e) receiving second image data generated by 
said second scan as said first and second 
scans progress; 

(f) receiving second status data from said sec- 
ond scanner as said first and second scans 
progress; 

(g) providing said first image data and said first 
status data to said first application program as 
said first and second scans progress; 

(h) providing said second image data and said 
second status data to said first application pro- 
gram as said first and second scans progress; 

(i) adjusting said first scan as said first and sec- 
ond scans progress; and 

. (j) adjusting said second scan as said first and 
second scans progress. 

17. The method of Claim 16, wherein (e) further com- 
prises adjusting said first scan based on said re- 
ceived first image data and said received first status 
data. 

18. The method of Claim 17, wherein (i) and (j) further 
comprise adjusting said first and second scans as 
directed by said first application program. 

19. The method of Claim 18, wherein said adjusting is 
automatic. 

20. The method of Claim 16, wherein (i) and (j) further 



comprise adjusting an imaging algorithm of said first 
scanner. 

21. The method of Claim 16, wherein (i) and Q) further 
5 comprise adjusting the imaging resolution of said 

first scanner. 

22. The method of Claim 16, wherein (i) and (j) further 
comprise adjusting the bit depth of said first scan- 

10 ner 

23. The method of Claim 1 6, wherein (g) and (h) further 
comprise providing said first and second image da- 
ta to a buffer area accessible by said first application 

15 program. 

24. The method of Claim 23, wherein said storage area 
comprises a hard drive. 

20 25. The method of Claim 23, wherein said buffer area 
is asynchronously accessible by said first applica- 
tion program. 

26. The method of Claim 16, wherein said first and sec- 
25 ond scans progress at a rate of approximately 65 

pages per minute. 

27. The method of Claim 16, wherein; 

(a) further compnses receiving in afirst module 
a first one or more generic commands gener- 
ated by said first application program to initiate 
said first scan, transmitting said first one or 
more generic commands to a second module 
coupled with said first module, translating said 
first one or more generic commands into a first 
one or more specific commands in said second 
module and transmitting said first one or more 
specific commands from said second module 
to said first scanner; 

(b) further comprises receiving in said first mod- 
ule a second one or more generic commands 
generated by said first appiication program to 
initiate said second scan, transmitting said sec- 
ond one or more generic commands to a third 
module coupled with said first module, translat- 
ing said second one or more generic com- 
mands into a second one or more specific com- 
mands in said third module and transmitting 
said second one or more specific commands 
from said third module to said second scanner; 

(c) further comprises receiving said first image 
data by said second module; 

(d) further comprises receiving said second im- 
age data by said third module; 

(e) further comprises receiving said first status 
data by said second module and transmitting 
said first status data from said second module 
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to said first module; 

(f) further comprises receiving said second sta* 
tus data by said third module and transmitting 
said second status data from said second mod- 
ule to said first module; and 

(g) further comprises transmitting said first Im- 
age data to said first application program from 
said second module and said first status data 
to said first application program from said first 
module; and 

(h) further comprises transmitting said second 
image data to said first application program 
from said third module and said first status data 
to said first application program from said first 
module. 

28. The method of Claim 27, wherein said third module 
is coupled with said first module in place of said sec- 
ond module. 

20 

29. The method of Claim 27, wherein said third module 
is coupled with said first module simultaneously 
with said second module. 

25 
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(57) A systenn and method for interfacing with pro- 
duction scanners is disclosed. A driver is provided which 
enables real-tinne conrimunications between a scanning 
application and scanner devices. The driver Includes an 
application program interface which is coupled with one 
or more personality modules, one for each scanner de- 
vice. The personality module facilitates the command 



and control of a particular scanner device. The applica- 
tion program interface can communicate with more than 
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es. The driver delivers resultant Image data from the 
scans to a commonly accessible buffer where the scan- 
ning application can asynchronously retrieve it. 
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